The present invention relates generally to diagnosing complex systems and devices including a large number of parts and components.
As today's technical systems generally become increasingly complex, efficient monitoring and detection of malfunctioning components is an area that gains progressive importance. Fault diagnosis algorithms may be applied to determine why an entity does not behave as intended. Typically, diagnosing the entity means selecting a subset of a predetermined set of causes responsible for the entity's incorrect behavior. A diagnosis should both explain the incorrect behavior and optimize some objective function, such as probability of correctness or cost of incorrect diagnosis. The need to diagnose is a common reason to measure or to test the entity. It is assumed that the entity consists of a finite number of diagnosed components. Further, failures of the entity are caused only by faults in at least one of these components.
In the artificial intelligence (Al) discipline, so-called consistency based diagnosis is the dominant methodology for fault isolation. This approach is strongly related to the methods for fault isolation used in fault detection and isolation (FDI), e.g. described in the article Nyberg, M. et al., “Combining AI, FDI, and statistical hypothesis testing in a framework for diagnosis”, Proceedings of IFAC Safe process '03, Washington, U.S.A., 2003.
A consistency based diagnosis points at one set of components whose abnormal behavior could explain why a system does not function as intended, and a set of diagnoses points at different such possible sets of components. However, the existing tools sometimes provide unclear conclusions regarding exactly which components that certainly are faulty, respective which components that are only suspected to be faulty, or normal. Nevertheless, this type of information would be useful, especially for a repair technician. Moreover, the known diagnostic systems lack indicators as to whether or not evaluation of additional test results would provide a more reliable diagnosis of the tested entity and its components. Hence, in today's solutions, it is unknown if a particular component has already been tested enough to determine a best possible estimate of its health status.
The term readiness is referred to in some prior art references, for instance EP 1 356 996 and JP 2004/151021. Here, the readiness status relates to single-component diagnostic tests, and designates whether or not the diagnosis system has yet had the opportunity to test a particular parameter or component. As soon as the relevant test has been completed, a ready status is assigned. Consequently, multiple-component diagnostic tests, wherein evaluation of several tests in respect of one component may be required cannot be handled.
Modern automotive vehicles often include a diagnostic system, which stores a diagnostic trouble code (DTC) when a component is found to be faulty. In the first generations of vehicular diagnostic systems, each diagnostic test checked exactly one component for faulty behavior. The DTCs could therefore be used to state exactly which components that where faulty and which components that where normal respectively. Recently, e.g. regulatory demands for reduced emission levels, have required introduction of diagnostic tests that simultaneously check the behavior of several components, i.e. multi-component tests or so-called plausibility tests. These general type of tests, e.g. being based on analytical redundancy relations (ARR), may come into conflict with the diagnostic framework that is based on the previously used single component tests.
From a DTC point-of-view, multi-component tests are problematic, since they can result in a non-binary component status, typically including a level between the normal and the faulty statuses that reflects a suspected fault status for one or more components. It therefore becomes unclear whether or not a suspected fault status should result in a DTC being set for the relevant components.
Modern automotive vehicles often include a number of electronic control units (ECUs), or agents. These units communicate over a network, and thus represent a distributed system. In such a system, a diagnostic test in one agent may check components that are physically and/or logically controlled by another agent. In this context, the agents may exchange information like sensor values, actuator values and calculated values. The multi-component tests should also be capable of handling this type of data streams.